Management system guidance
8.3 Design and development of products and services
ISO Navigator Pro™ is a free tool that provides practical, expert guidance for businesses wishing to interpret and better implement the requirements of ISO 9001:2015, ISO 14001:2015 and ISO 45001:2018.
Our range of templates cover the requirements of ISO 9001:2015, ISO 14001:2015 and ISO 45001:2018, and offer an easy way to implement your next management system.
8.3.3 Design and development inputs
This requirement expands upon the requirements from ISO 9001:2008 Clause 7.3.2 - Design and Development Inputs 7.3.1. You should seek and record evidence that your organization has documented and retained information concerning the need for internal and external resources and the potential consequences of design or development failure. If you need a procedure and forms to help control your business's design and development process, click here.
Define which design and development inputs are required to carry out the design and development process. The inputs should be determined according to the design and development activities. For example, which employees are required or what information is required for every step of the development process. When determining design input requirements, ensure the retention of documented information such as:
- Statutory and regulatory requirements e.g. legislation, regulation, directives;
- Standards or codes of practice e.g. policies, standards, specifications, rules and aids, protocols, guidance, industry codes
- Functional and performance requirements informed by customer requirements, operational and performance charateristics, usability, reliability, availability, maintainability, and safety (e.g. Human factors and RAMS);
- Knowledge exchange from other, similar proven designs, lessons-learned, performance data, in-service data, customer feedback, external feeback, best practice, benchmarking;
- Design assumptions and associated risks;
- Methods of validation and verification;
- Adequacy of inputs e.g. clear, complete, unambiguous, and authorized;
- Conflicting inputs are resolved by communicating with interested parties/contract amendments.
The auditor will need to review evidence that the inputs have been addressed based on the nature of the product being produced, that they have been reviewed for adequacy and that records are maintained of the activity. An organization may include design personnel in the contract review stage; these records may suffice the review of design input requirement.
Conceptual Design Statement (CDS)
The Conceptual Design Statement (CDS) includes a design statement that declares the inputs to be used in the design and the proposed design solution. A design statement illustrates the principles concepts and input data relevant to the design and allows relevant stakeholders to understand the thinking behind any chosen design solution.
The Design Team will normally produce a Conceptual Design Statement that states the standards and requirements against which the design is to be developed, the processes to be applied and the level of independent checking to be carried out (if any) that is proportionate to the level of risk. The design activities are then carried out by the Design Team using the CDS as the basis.
Design and development inputs are documented and controlled. Design and development inputs can be in any form, including data sheets, customer drawings and specifications, photographs, samples, references to standards, etc.
Design standards baseline
All designs are based on a list of approved design standards, referred to as the Standards Baseline. This list is owned and managed by the Engineering Manager. The Standards Baseline is made up of a combination of National and International Standards, National Engineering Specifications, and Approved Codes of Practice.
The Standards Baseline should be reviewed monthly and any changes are controlled by the Engineering Manager. At the commencement of any given design package, the Design Team is required to specify the Standards Baseline that will be used in the design.
The Engineering Manager should be responsible for checking that the correct design standards have been specified and for verifying that the design output complies with these standards and design requirements.
Due to the continuous review and updating of standards, the baseline between different design instructions may vary so a strict configuration control is maintained and only agreed changes are used in the assurance process. Once a design package has been instructed, the baseline for that element of work becomes fixed and will not reflect any subsequent changes in standards.
Design assumptions
Assumptions will normally be statements to fill uncertainties in available information. They are generated by the Design Team in order to allow designs to continue in the early stages. The anticipation is that assumptions are temporary and are closed out either by obtaining data or updating documents to confirm or change the assumption.
Assumptions have the potential to be incorrect, and are therefore a source of risk, that require management. Any associated risk is identified and raised through the Risk Register. The assumption management activity is coordinated by Design Manager, with input from the Design Team.
Assumptions regarding domain knowledge include facts about the application of the end product or service that allow requirements to be developed in a particular context. The assumptions are normally traceable to gaps or inconsistencies in the design inputs e.g. incomplete or conflicting functional requirements, inconsistencies between the applicable Standards, unclear scope of work, or demarcation issues.
The Responsible Body; which might be another company, organisation, person, or team against which an assumption has been made or who are responsible for providing a feature or undertaking an action to resolve an assumption agreed by them. Qualifying criteria for design assumptions are based on the following:
- Assumptions on scope and allocation;
- Assumption regarding gap or conflict in the stated capabilities, systems or operational aspects;
- Conflict between standards;
- Assumptions due to missing design data;
- Assumptions regarding a design decision;
- Assumptions relating to interface issues.
Assumptions must not be raised on programme and cost related matters. The requirements or the design statement will be verifiable against the raised assumption or the origin of the assumption. Assumptions are accepted by the Resolving Body; they may be turned into design requirements or project risks. The process for managing design assumptions is summarised as follows:
- Assumptions are managed using an Assumptions Register;
- The Design Team propose an assumption to fill an uncertainty;
- The Engineering Manager reviews the suitability of the assumption against the criteria;
- Once agreed with the Resolving Body, the Design Team updates the assumption register;
- Action owner closes out assumption by agreed date, this could be done either by establishing additional data or confirming a decision;
- The Engineering Manager monitors that action owners are closing out assumptions and takes action to expedite if necessary;
- Any assumption remaining at the end of the design phase must be clearly recorded in the Assumptions Register and transferred to the Risk Register.
Assumptions are considered closed when they are successfully resolved i.e. accepted by the Resolving Body and the Resolving Body has taken an action that is documented in a resolving document. This resolving document must be properly reviewed, verified and issued before the closure of an assumption is accepted.
The respective Gate Review Authority are the final authority to accept or reject the closure of an assumption. The confirmation of closure is noted in the Assumptions Register and a reference to the resolving document with the relevant clause is provided for verification purposes.
Design requirements
The design management process is geared towards meeting customer requirements, while providing a product cost, which enables organizations to have a satisfactory return on investment. The physical and performance requirements of a product used as a basis for product design and development; includes user requirements, regulatory requirements, and system requirements.
The customer and user requirements are translated into design requirements and may either be hardware or software (according to intended use) and included in the design specifications and other design documents.
The requirements are reviewed for adequacy by a cross functional, multidisciplinary team involving Design, Engineering, Sales, Manufacturing, Procurement, Sales and Quality to ensure the requirements are complete, unambiguous and not in conflict with each other. The Design Team notifies Engineering Manager if the requirements are ambiguous or conflict with each other.
The Design Team produces evidence of the capture of and compliance with the requirements. This evidence is presented in the Requirements Register. The Design Team should provide compliance matrices and verification reports to demonstrate how the designs meet the requirements, supported by the compliance rationale, evidence, models and analysis as required, whilst ensuring that:
- All requirements are traceable to the identifier, author, rationale, source, requirement owner, allocation and stakeholder;
- All requirements have been validated and approved by identified personnel;
- All requirements set been reviewed and agreed with the customer;
- Are requirements are recorded into the project applicable database;
- All allocated requirements are understood and accepted by all the recipients.
In order to progress their close-out and acceptance, compliance statements are prepared and allocated to each requirement, commensurate to the design stage e.g. Gate 1, 2, or 3. Links and references to supporting drawings and documents are provided as the design progresses.
Customer supplied user requirements are transferred to the Requirements Review Checklist and additional requirements are addressed with the customer. The Marketing Manager and the Sales Manager should identify and document the markets’ need for new solutions in a requirement statement which serves as the input for design and development work. The requirement statement includes the following:
- What is required (features/functions, etc.);
- Why it is needed (customer demand);
- When it is needed;
- Assumptions needed to progress the design;
- Risk and opportunity, and hazard analysis;
- Requirements for performance, reliability, safety, statutory and regulatory, etc.;
- Pricing targets and design project milestones.
When a product is designed or modified to meet specific customer requirements, the Engineering Manager receives from Marketing Manager and the Sales Manager an outline design order with customer requirements and specifications. The Design Team translates the needs and expectations from the requirements and design statements to technical specifications for materials, products, services and processes.
Design interfaces
Where necessary, the Design Team should form working groups to develop interface control documents and record agreements for interfacing stakeholders in order to elicit their requirements and to provide feedback that may be important to your designs.
Their emphasis should be on the identification and co-ordination of the important characteristics, parameters and configurations that need to be developed to deliver effective interface designs. The level of detail documented must be proportionate with the level of detail being developed in the design outputs.
- Identify, specify and manage interfaces;
- Assist in the resolution of interface issues relating to commercial or contractual issues;
- Assist in the production of and agree interface documents with interfacing parties;
- Ensure that the process of interface management is fully supported during the development of detailed designs;
- Review and monitor the development of interface identification.
Design documentation
The established document numbering system must be used by the Design Team. All documents produced to support the design and the design assurance process should be listed in the Master Design Document List, which is a list of all plans, processes and procedures to be used to control the safety, quality and efficiency of the design output.
All design documents must follow the ‘Prepare’, ‘Check’, and ‘Approve’ process, evidenced by the signatures of competent individuals. All design documents should be signed off in the three categories:
- Prepared – by a competent person who produces the design document, checking their own work complies with codes and standards governing that work.
- Checked – by a competent person able to undertake a formal detailed check/review of design methods, codes and standards used, deliverables, calculations, drawings and specifications produced by another member of the Design Team. This role is undertaken by a competent person of the same discipline, not the Preparer, but can be a member of the same team.
- Approved – by a competent person of the same discipline, but not a member of the same team, able to undertake a review of the design output after detail checking has taken place to validate that the design is consistent with requirements, is fully integrated and satisfies interface requirements.
Design and development reference materials (e.g. standards, catalogues, etc.) should be available and maintained by the Engineering Manager. Only current issues and revisions of reference material must be used. All documents produced to support the design and the design assurance process must be listed in the Master Design Documents List.
More information on PDCA
Planning
Context
Planning
Support
Doing
Support
Operations
Checking
Monitoring, measurement, analysis and evaluation
Acting
Improvement
Want to know more?
- Read our customer's feedback
- Client list - who's using our templates?
- How the templates are formatted and download examples
- Why we use turtle diagrams and process maps
- What's the difference between a process and a procedure?
- About documented information
SSL certification
A certificate guarantees the information your internet browser is receiving now originates from the expected domain - https://www.iso9001help.co.uk. It guarantees that when you make a purchase, sensitive data is encrypted and sent to the right place, and not to a malicious third-party.
Free PDCA guidance
ISO Navigator™ is our FREE online training tool that shows you how to apply the principles of PDCA to your operations. We also offer many helpful templates that get you on the road to documenting your management system, please visit the download page.